Configuring Power Management Functionality In A Processor

ABSTRACT

In one embodiment, a multicore processor includes cores that can independently execute instructions, each at an independent voltage and frequency. The processor may include a power controller having logic to provide for configurability of power management features of the processor. One such feature enables at least one core to operate at an independent performance state based on a state of a single power domain indicator present in a control register. Other embodiments are described and claimed.

TECHNICAL FIELD

Embodiments relate to power management of an integrated circuit.

BACKGROUND

Advances in semiconductor processing and logic design have permitted anincrease in the amount of logic that may be present on integratedcircuit devices. As a result, computer system configurations haveevolved from a single or multiple integrated circuits in a system tomultiple hardware threads, multiple cores, multiple devices, and/orcomplete systems on individual integrated circuits. Additionally, as thedensity of integrated circuits has grown, the power requirements forcomputing systems (from embedded systems to servers) have alsoescalated. Furthermore, software inefficiencies, and its requirements ofhardware, have also caused an increase in computing device energyconsumption. In fact, some studies indicate that computing devicesconsume a sizeable percentage of the entire electricity supply for acountry, such as the United States of America. As a result, there is avital need for energy efficiency and conservation associated withintegrated circuits. These needs will increase as servers, desktopcomputers, notebooks, ultrabooks, tablets, mobile phones, processors,embedded systems, etc. become even more prevalent (from inclusion in thetypical computer, automobiles, and televisions to biotechnology).

Power and thermal management issues are considerations in all segmentsof computer-based systems. While in the server domain, the cost ofelectricity drives the need for low power systems, in mobile systemsbattery life and thermal limitations make these issues relevant.Optimizing a system for maximum performance at minimum power consumptionis usually done using the operating system (OS) or system software tocontrol hardware elements. Most modern OS's use the AdvancedConfiguration and Power Interface (ACPI) standard (e.g., Rev. 3.0b,published Oct. 10, 2006) for optimizing the system in these areas.

An ACPI implementation allows a processor core to be in differentpower-saving states or C-states (also termed low power or idle states),generally referred to as C0 to Cn states, with C0 being the active stateand higher ones being deeper sleep states. In addition to power-savingstates, performance states or so-called P-states are also provided inACPI. These performance states may allow control of performance-powerlevels while a core is in an active state (C0). In general, multipleP-states may be available, from P0-PN. There can be a range of higherfrequency/performance states that are generally referred to as turbomode.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a portion of a system in accordance with anembodiment of the present invention.

FIG. 2 is a flow diagram of a method for handling performance staterequests received from threads within a multicore processor inaccordance with one embodiment of the present invention.

FIG. 3 is a block diagram of a processor in accordance with anotherembodiment of the present invention.

FIG. 4 is a block diagram of a traffic sensor in accordance with anembodiment of the present invention.

FIG. 5 is a block diagram of a processor in accordance with anembodiment of the present invention.

FIG. 6 is a block diagram of a processor core in accordance with oneembodiment of the present invention.

FIG. 7 is a block diagram of a multicore processor in accordance withanother embodiment of the present invention.

FIG. 8 is a block diagram of a system in accordance with an embodimentof the present invention.

DETAILED DESCRIPTION

Embodiments provide techniques to efficiently and configurably operate aprocessor at dynamic power/performance levels to enable the processor tobe finely tuned within a system to address issues for a given type ofplatform in which the processor is configured. Embodiments may beparticularly suitable for a multicore processor in which each ofmultiple cores can operate at an independent voltage and frequencypoint. As used herein the term “domain” is used to mean a collection ofhardware and/or logic that operates at the same voltage and frequencypoint. In addition, a multicore processor can further include othernon-core processing engines such as fixed function units, graphicsengines, and so forth. Such processor can include independent domainsother than the cores, such as one or more domains associated with agraphics engine (referred to herein as a graphics domain) and one ormore domains associated with non-core circuitry, referred to herein asan uncore or a system agent. Although many implementations of amulti-domain processor can be formed on a single semiconductor die,other implementations can be realized by a multi-chip package in whichdifferent domains can be present on different semiconductor die of asingle package. As used herein, the terms hardware thread, thread, andlogical core are all used interchangeably.

According to an OS-based ACPI mechanism, a processor can operate atvarious power and performance states or levels. With regard to powerstates, ACPI specifies different power consumption states, generallyreferred to as C-states, C0, C1 to Cn states. When a core is active, itruns at a C0 state, and when the core is idle it may be placed in a corelow power state, also called a core non-zero C-state (e.g., C1-C6states). When all cores of a multicore processor are in a core low powerstate, the processor can be placed in a package low power state, such asa package C6 low power state.

In addition to these power states, a processor can further be configuredto operate at one of multiple performance states, P-states, namely fromP0 to PN. In general, the P1 performance state may correspond to thehighest guaranteed performance state that can be requested by an OS. Inaddition to this P1 state, the OS can further request a higherperformance state, namely a P0 state. This P0 state may thus be anopportunistic state in which, when power and thermal budget isavailable, processor hardware can configure the processor or at leastportions thereof to operate at a higher than guaranteed frequency. Inmany implementations a processor can include multiple so-called binfrequencies, also referred to herein as turbo mode frequencies, abovethis P1 frequency. The highest such frequency may correspond to amaximum turbo frequency (P01), which is the highest frequency at which adomain can operate. This maximum turbo frequency thus is the highest endof multiple turbo mode frequencies greater than the P1 frequency andcorresponds to a maximum non-guaranteed highest performance level thatcan be achieved. As will be described herein, turbo can beenabled/disabled across all cores or on a hardware thread basis.Embodiments provide a configuration mechanism to operate in conjunctionwith turbo controls that are at a package level and individual corelevel (via the hardware thread). Note that the terms “performance state”or “P-state” can be interchangeably used with the term “operatingfrequency” (or more generally “frequency”) as the frequency at which acore operates has a direct correlation to its performance. Thus as usedherein a higher performance state correlates to a higher operatingfrequency.

A processor in accordance with an embodiment of the present inventionmay include a fully integrated voltage regulation (FIVR) such that percore P-states (PCPS) can be provided. In this way, cores can be operatedat frequencies independently of each other.

Although the following embodiments are described with reference toenergy conservation and energy efficiency in specific integratedcircuits, such as in computing platforms or processors, otherembodiments are applicable to other types of integrated circuits andlogic devices. Similar techniques and teachings of embodiments describedherein may be applied to other types of circuits or semiconductordevices that may also benefit from better energy efficiency and energyconservation. For example, the disclosed embodiments are not limited toany particular type of computer systems, and may be also used in otherdevices, such as handheld devices, systems on chip (SoCs), and embeddedapplications. Some examples of handheld devices include cellular phones,Internet protocol devices, digital cameras, personal digital assistants(PDAs), and handheld PCs. Embedded applications typically include amicrocontroller, a digital signal processor (DSP), network computers(NetPC), set-top boxes, network hubs, wide area network (WAN) switches,or any other system that can perform the functions and operationsdescribed below. Moreover, the apparatus', methods, and systemsdescribed herein are not limited to physical computing devices, but mayalso relate to software optimizations for energy conservation andefficiency. As will become readily apparent in the description below,the embodiments of methods, apparatus', and systems described herein(whether in reference to hardware, firmware, software, or a combinationthereof) are vital to a ‘green technology’ future, such as for powerconservation and energy efficiency in products that encompass a largeportion of the US economy.

Although a processor can have various dynamic power/performancefeatures, embodiments may be used to provide configurability of some orall of such features. For purposes of illustration herein, three dynamicpower/performance features will be described in detail: Per CoreP-States (PCPS), uncore frequency scaling (UFS), and energy efficientturbo (EET).

The PCPS feature allows individual cores of a multicore processor toconcurrently operate at different frequencies within the overall power,electrical, thermal and stock keeping unit (SKU) constraints. The UFSfeature uses sensor values to dynamically adjust uncore interconnectfrequency to better allocate power between cores and uncore interconnectto increase performance, and under idle scenarios to conserve power. TheEET feature dynamically adjusts frequency in a turbo range for a corebased on core stalls (e.g., when one or more threads executing on a coreare waiting for either a load or store). Since a stalled core, eitherdue to workload mix or application memory access patterns, is notfrequency friendly and unable to provide improved performance fromincreased operating frequency, EET operation can improvepower/performance tradeoffs in a processor.

In various embodiments, configurable parameters may be provided toenable a user to mix and match the above features (and/or otherpower/performance features). In addition, these features may be made tobe configurable, allowing fine tuning of a system to meet the needs ofdifferent market segments, including but not limited to cloud computing,high performance computing, data centers, and storage, among others. Inthis way, a single processor can provide power and performance featuresthat can be implemented with differentiated selection across the computecontinuum, with a wide range of usage models.

In various embodiments, PCPS enables operation of individual physicalcores at different voltage/frequency points concurrently based on OSrequested performance on the logical cores associated with a physicalcore. That is, the operating point of each core can be configuredindependently of the other cores (within overall system power andthermal constraints). In one embodiment of the invention, PCPS isfeasible due to a fully integrated voltage regulator (FIVR) that isintegrated in the processor. This regulator allows independentconfiguration of each core, wherein the configuration includes, but isnot limited to, voltage setting, frequency setting, and other parametersthat affect the power consumption of each core.

In contrast to operating all cores of a multicore processor at a commonvoltage/frequency point that is the maximum of the OS requestedperformance across all logical cores, PCPS can enable power savings byrunning physical cores only as high as the OS determines is appropriate.Embodiments can increase performance by way of allocating excess powerbudget to only cores that seek it, allowing them to run faster andincrease system performance.

In one embodiment of the invention, the processor has a plurality ofprocessing cores and a power control module that is coupled with each ofthe plurality of processing cores. The power control module facilitateseach core to operate at a performance state that is independent of theperformance state of other cores, where the overall thermal andelectrical constraints of the package or system are not violated. Inthis way, better control over power consumption and performance can berealized. For example, in a multicore processor only a few cores may beenabled to run at a higher core frequency in a thermally constrainedenvironment, enabling execution of a desired workload while reducingpower consumption and thus temperature.

In a FIVR implementation in which each core within a processor has itsown voltage regulator, one or more additional voltage regulators may beprovided for use with other components within a processor such as uncorelogic, memory controller logic, power control unit, and so forth. Ofcourse, in some embodiments a single voltage regulator may be associatedwith one or more cores and/or other components of a processor. In oneembodiment, a dedicated voltage regulator may be provided for uncorecircuitry of a processor, which would allow the uncore to run at adifferent voltage and frequency. For a compute centric workload, theuncore can be run at a lower voltage and frequency, resulting inapplying power savings toward higher core frequencies at a socket level.For memory and IO intensive workloads, the uncore can be run at a highervoltage and frequency, while the cores can run at lowervoltages/frequencies, compensating for higher power consumption in theuncore.

In some embodiments, ACPI tables may be extended to include informationregarding these individual integrated voltage regulators to enable percore P-state control. For example, a 4-bit field may be used to passP-state information and map it to control voltage logic for eachregulator. Thus using embodiments of the present invention, each coremay be controlled to operate at a different frequency and/or voltage foran asymmetric workload. As one example, one or a few of multiple corescan be controlled to operate at higher frequencies and/or voltages whilethe remaining cores are controlled to operate at lower voltage/frequencycombinations to thus stay within a given thermal design power (TDP)envelope. In this way, deterministic and optimal performance capabilityselection can be realized for given workloads.

For example, cores that seek a higher performance level to process datain a first manner can operate at a higher voltage/frequency (such coresmay execute tasks such as data processing usage such as data-duplicationservices, data analytics, parity computations or so forth), while coresexecuting, e.g., management tasks, can run at lower voltages/frequenciesto provide for an optimal mix for a TDP-constrained environment. Thusrather than opportunistically running all cores at a higher frequencywhen possible (as with a so-called turbo mode) given a thermal or TDPbudget, embodiments provide for deterministic behavior on an individualcore basis.

Referring now to FIG. 1, shown is a block diagram of a portion of asystem in accordance with an embodiment of the present invention. Asshown in FIG. 1, system 100 may include various components, including aprocessor 110 which as shown is a multicore processor. Processor 110 maybe coupled to a power supply 150 via an external voltage regulator 160,which may perform a first voltage conversion to provide a primaryregulated voltage to processor 110.

As seen, processor 110 may be a single die processor including multiplecores 120 _(a)-120 _(n). In addition, each core may be associated withan individual voltage regulator 125 _(a)-125 _(n). Accordingly, a FIVRimplementation may be provided to allow for fine-grained control ofvoltage and thus power and performance of each individual core. As such,each core can operate at an independent voltage and frequency, enablinggreat flexibility and affording wide opportunities for balancing powerconsumption with performance.

Still referring to FIG. 1, each core can include various hardwaresensors and other circuitry than can provide information for use inperforming dynamic control of multiple power management features of aprocessor in accordance with an embodiment of the present invention.More specifically as shown in FIG. 1, each core can include a coreactivity sensor 122 and a core stall sensor 124.

In one embodiment, core stall sensor 124 may be configured to determinea stall rate of a core which corresponds to a measure of waiting forstores/loads. This stall rate can be determined in various manners,ranging from a simple count of cycles for which the core is stalled tomore complicated manners.

In one embodiment, core activity sensor 122 may be configured todetermine an activity rate of a core. This activity rate can bedetermined in various manners, ranging from a simple count of cycles forwhich the core is active to more complicated manners. In one embodiment,core activity sensor 122 can be configured to count cycles in which oneor more threads on a core is in an active C0 state. Without loss ofgenerality assume a physical core is associated with two logicalprocessors or hardware threads, then the core has an active or C0 valuethat equals the time when one or more associated logical cores isactive, that is, in a C0 state during the observation window.

Still referring to FIG. 1, additional components may be present withinthe processor including an input/output interface 132, another interface134, and an integrated memory controller 136. As seen, each of thesecomponents may be powered by another integrated voltage regulator 125_(x). In one embodiment, interface 132 may be in accordance with theIntel® Quick Path Interconnect (QPI) protocol, which provides forpoint-to-point (PtP) links in a cache coherent protocol that includesmultiple layers including a physical layer, a link layer and a protocollayer. In turn, interface 134 may be in accordance with a PeripheralComponent Interconnect Express (PCIe™) specification, e.g., the PCIExpress™ Specification Base Specification version 2.0 (published Jan.17, 2007). While not shown for ease of illustration, understand thatadditional components may be present within processor 110 such as uncorelogic, a power control unit, and other components such as internalmemories, e.g., one or more levels of a cache memory hierarchy and soforth. Furthermore, while shown in the implementation of FIG. 1 with anintegrated voltage regulator, embodiments are not so limited.

In various embodiments, PCPS enables operation of individual physicalcores at different voltage/frequency points concurrently based on OSrequested performance on the logical cores associated with a physicalcore. In contrast to operating all cores of a multicore processor at acommon voltage/frequency point that is the maximum of the OS requestedperformance across all logical cores, PCPS can enable power savings byrunning physical cores only as high as the OS determines is appropriate.Embodiments can increase performance by way of allocating excess powerbudget to only cores that seek it, allowing them to run faster andincrease system performance.

Accordingly, PCPS configuration allows clubbing all cores into a singlepower domain or having a power domain per core. The number of powerdomains in turn affects the implementation of certain legacy P-statebehavior, namely certain ACPI parameters including a SW_ANY controlparameter, described below.

Basic Input Output System (BIOS) support for PCPS includes aconfiguration flag and table entries. More specifically, a single powerdomain (SPD) indicator or flag may be present in a configuration andstatus register (CSR), e.g., as a bit of the register. This bit may belocked down and read only once on system reboot/reset. In an embodiment,when this bit is set it is an indication that the processor is to act asa single domain for power purposes (and thus all cores operate at asingle P-state). Instead when this bit is reset, it is an indicationthat each core of the processor is to act as a single domain for powerpurposes (and thus each core can operate at an independent P-state).

PCPS support may also be realized via ACPI table entries in BIOS perpower domain. To realize PCPS in a N physical core system, N ACPI powerdomain entries can be specified. To treat all cores as mapping to asingle power domain, a single entry of these multiple entries can bespecified. Or a separate entry can be provided to be used when all coresare to map to a single power domain.

On system reboot, the ACPI tables and the SPD flag are read once. Ifthere are multiple power domain entries and the SPD flag is not set, thefull feature of PCPS can be made transparently available to systemsdeployed with a legacy operating system that does not have support forPCPS.

According to the ACPI specification, different power management modesare possible, with each mode indicating what effect a performance statechange request from a thread has on a power domain. In general, threedifferent power management modes are available, namely HW_ALL, SW_ALLand SW_ANY. In general, HW_ALL and SW_ALL operate similarly in that ahighest requested performance state of the active threads within a givenpower domain is selected as the performance state to be applied to thatpower domain. Instead, the SW_ANY power management mode is to cause theperformance state of a power domain to be that of the performance statemost recently requested by an active thread on that domain.

Referring now to Table 1, shown is behavior to support ACPI modes ofHW_ALL, SW_ALL, SW_ANY using this SPD flag along with a single powercontrol (PCTL) flag, which may be available on a miscellaneous powermanagement machine specific register (MSR) (e.g., MISC_PWR_MGMT (MSR0x1aa)), and generally provides the configuration of either single powercontrol or multiple domain power control, depending on a state of theflag.

TABLE 1 Single Power Single Domain PCTL Core (flag) (flag) ACPI Mode(s)Frequency(s) Description 0 0 HW_ALL Multiple Core P-state is maximum ofSW_ALL (PCPS) thread P-state requested on active threads in powerdomain, in this case comprised of a single physical core 0 1 SW_ANYMultiple Core P-state is last (PCPS) requested thread P-state on threadsassociated with the power domain, in this case comprised of a singlephysical core 1 0 HW_ALL Single All cores at single P-state SW_ALL equalto the maximum P- state requested by active hardware threads in thepower domain, which is comprised of all the physical cores in thepackage 1 1 SW_ANY Single All cores at single P-state equal to the lastrequested P-state across all threads in package

Table 2 shows an illustration of behavior for legacy OS's based onwhether BIOS to support PCPS is provided.

TABLE 2 Single Legacy_OS BIOS_change PCTL Effect Description X 0 0 1power domain Single P-state, max across all threads P- state X 0 1 1power domain Single P-state, last requested thread P- state X 1 0 Npower domains PCPS, max P-state of threads on each core X 1 1 N powerdomains PCPS, last thread request per core Note in the above Table 2, Xis a don't care, and N corresponds to the number of cores in theprocessor.

Referring now to Table 3, shown is pseudocode for P-state handling thatleverages the configurability of PCPS in accordance with an embodimentof the present invention.

TABLE 3 Event: OS Pstate or Cstate request on any logical core (namely,a hardware thread), say t, Pstate(t) // If the Cstate is C0, implieslogical core active, and hence its Pstate is considered // if Cstate >0, that is inactive, the associated Pstate is disregarded  if(single-power-domain) { //SPD   if (SW_ANY mode) { // Single_PCTLflag/bit    new_Pstate = Pstate(t); // available on IO_FIRMCONFIG_MSR  } else { // SW_ALL & HW_ALL    new Pstate = max (Pstate of all logicalcores that are in C0 Cstate (aka active));   // Hardware consolidationof max Pstate across logical cores associated with a //physical corespeeds this as opposed to firmware computation of the same across all//physical cores.   } else { // SW_ALL & HW_ALL & SW_ANY     //Implemented in hardware and available as a field in a physical corelevel   IO register     New_Pstate = max (Pstate of all sibling logicalcores on associated   physical core associated in C0 Cstate);   }   if(New_Pstate != Old_Pstate) {   // initiate core operating point changeflow }

As seen in Table 3, it is possible for a user to define multiple powerdomains in the BIOS and disable the SPD flag to reap PCPS power andperformance benefits, and further to set the single PCTL flagaccordingly to determine whether all active threads or the most recentlyrequested thread P-state determines core P-state. Other users may usePCPS while supporting ACPI modes including HW_ALL and SW_ALL. Also,deployments with a legacy OS may disable the SPD flag and enumerate apower domain entry per physical core. For deployments that seek to runall their cores at the same frequency at all times, such as a cloudservice environment where simplifying client billing is sought,regardless of OS (legacy or new), the SPD flag can be set, ensuring thatall cores operate at the same voltage/frequency point and are usingresources equally in that respect. As an example, when a cloud serviceprovider installs a smarter metering system, PCPS may be enabled andmore performance and power savings are obtainable and the user can becharged accordingly. In domains where greater single threadedperformance is desired, PCPS with the SPD flag reset may be the optimaldeployment. A customer who seeks to benefit from new processor hardwareand not have the time to experiment with PCPS can run a system with SPDflag set.

Referring now to FIG. 2, shown is a flow diagram of a method forhandling performance state requests received from threads within amulticore processor. As seen, method 200 begins by receiving a powerand/or performance state request from a thread (block 210). Note thatthis thread may be a hardware thread or logical core, and the requestmay be received in a power controller of the processor such as a powercontrol unit (PCU). Alternately, the request may be received within acore of the processor on which a PCPS algorithm executes.

Still referring to FIG. 2, at diamond 220 it can be determined whetherthe core on which this thread is executing is in a low power state. Ifso, the request can be ignored and control passes to diamond 222 whereit can be determined whether all cores in the package are in a low powerstate. If so, control passes to block 225 where the package can enter asleep state. If instead at diamond 222 it is determined that not allcores in the package are in a low power state, control passes to block228 where this core can enter a sleep state to save power. Note that ifall the threads on a given core are in a low power state, the core maythus be put into a sleep or other low power state to enableredistribution of power to other cores that are more active. Thus when acore enters into a low power state, the power otherwise allocated tothat core may be harvested for distribution among other cores, e.g., toenable one or more of the cores to enter into a turbo mode. If insteadall cores in a package are in a sleep state, the package overall may beplaced into a sleep state to reduce power consumption.

If the core is not in a low power state, control passes to diamond 230where it can be determined whether the processor is configured tooperate in a single power domain mode. In an embodiment, thisdetermination may be based on an SPD indicator, e.g., present in acontrol register of the processor.

Referring still to FIG. 2, if at diamond 230 it is determined that theprocessor is operating in a single power domain mode, control passes todiamond 240 where it can be determined whether a first power managementmode is active. In an embodiment, this first power management mode maycorrespond to an ACPI mode of SW_ANY. In an embodiment, thedetermination of the power mode in which the processor is operating canbe obtained from a field of a MSR. In turn, other power modes includinga HW_ALL mode and a SW_ALL mode can be determined by OS behavior, whichtracks at a high level application behavior and policy and is the masterthat sets the per thread register values for P-state changes.

Thus at diamond 240 if it is determined that the first power managementmode is active, control passes to block 260 where the candidateperformance state for all cores can be set to the requested performancestate. That is, in this first power mode, the most recent performancestate request is controlling and thus all cores may be commonly set atthis requested performance state.

If instead at diamond 240 it is determined that the first powermanagement mode is not active, control passes to block 250 where thecandidate performance state for all cores can be set to a maximumrequested performance state of all active cores. In this situation, ascan across the active threads of all cores can be made to thusdetermine the maximum requested performance state and to enable controlof the processor to this performance state.

If it is determined that the processor is operating in a single powerdomain mode, control passes to block 270 where it can be determinedwhether the first power management mode is active. If so, control passesto block 272 where the candidate performance state for the core can beset to the requested performance state. Otherwise if the first powermanagement mode is not active, control passes to block 274, where thecandidate performance state for the core can be set to the maximumrequested performance of all active threads on the core. In this way, aper core performance state operation can be realized and each core canexecute at an independent performance state. As such, greaterperformance can be achieved while conserving power as possible.

From all of blocks 250, 260, 272, and 274 control next passes to diamond280 to determine whether the newly set candidate performance state isdifferent than the prior active performance state. If not, the methodmay conclude. Otherwise, if a difference in performance states exists,control passes to block 290 where the power controller can perform achange to thus move the appropriate power domain operation to the newlyset performance state. Although shown at this high level in theembodiment of FIG. 2, understand the scope of the present invention isnot limited in this regard.

As described above, UFS enables dynamic control of uncore interconnectfrequency to better allocate power between cores and uncore to increaseperformance. Embodiments may monitor various information, including butnot limited to interconnect traffic, core activity levels, and otherinformation to determine usage of uncore circuitry of a processor, todetect congestion and under-utilization. This information can be used toadapt the operating frequency of such circuitry to changing workloadcharacteristics, and thus gain power and performance benefits. Note thatthis uncore circuitry can include interconnect structures to couplecores to caches and other on-chip and off-chip circuitry, one or morecache memories, as well as certain non-core logic circuitry such as aPCU and so forth.

When a processor package is in an idle state, namely when all of thecores are in a low power state, the only traffic stems from attachedinput/output (IO) devices and sibling sockets in a multi-socket system.In such cases, the interconnect operating frequency may be reduced to avalue sufficient to comfortably meet the IO and intersocket trafficneeds, which is referred to herein as an IO traffic threshold frequency.Although the scope of the present invention is not limited in thisregard, in some embodiments this threshold frequency may be betweenapproximately 1.2 and 4.0 gigahertz (GHz) as examples.

Different information regarding actual usage of an interconnect may beevaluated in determining an appropriate frequency for operating theuncore. In one embodiment, such information can be obtained from avariety of sensors and detectors, including the core activity sensor andcore stall sensor described above. Using information from these sensors,information regarding uncore contention, pressure in the shared cache,or bandwidth limitations may be discerned. However, core stalls do notprovide visibility into localized congestion along the interconnect, norconclusively indicate under-utilization, information regarding both ofwhich may be valuable for better power utilization and performance.

To this end, embodiments may also provide a set of distributedconfigurable traffic sensors that can be used to measure traffic atvarious points within the uncore circuitry. In one embodiment, suchsensors can be located at each interface unit coupled to theinterconnect, e.g., at each interconnect stop, where the interconnect isconfigured as a ring interconnect. However, other topologies can be aring, mesh, star, tree, among many others. The traffic sensors may beused to measure traffic along each direction, of each data type, andalong each interconnect segment. Embodiments thus may monitor usage ofan interconnect to detect traffic congestion, under-utilization, anduncore contention.

The PCU receives all sensor data and uncore frequency control logic ofthe PCU may be used to analyze the data to adapt the uncore frequency asnecessary. The goal of an uncore frequency scaling algorithm inaccordance with an embodiment of the present invention is to allocatepower between core and interconnect power planes, to increase overallsystem performance and possibly save power. In each power plane bothvoltage and frequency can be modified.

Referring now to Table 4, shown is pseudocode for a uncore frequencyscaling algorithm in accordance with one embodiment of the presentinvention.

TABLE 4 UFS Algorithm every ADAPT_PERIOD { // configurable period   i =(i + 1) mode n; // n sliding window size   int dyn_uncore_ratio =current_uncore_ratio;   if (package_idle) { // all cores in socket idle    dyn_uncore_ratio = max(QOS_UNCORE_FLOOR , IO_Plimit);   } else {    higher_uncore_ratio = min((current_uncore_ratio +      UFS_RATIO_INC_STEP), MAX_UNCORE_RATIO);     lower_uncore_ratio =max((current_uncore_ratio −   UFS_RATIO_DEC_STEP),      QOS_UNCORE_FLOOR );     int recommend = 0; // no change     if((num_cores_stalled > (num_cores_active *    TOLERATE_CORES_STALL_FACTOR)) ||       (max_uncore_traffic >=comfortable_max(current_uncore_ratio)) {       recommend = +1;     }else if (max_uncore_traffic <= comfortable_max(lower_uncore_ratio)) {      recommend = −1;     }     // recommendBuf is a circular buffer, topreserve the last n     recommendations for hysterisis    recommendBuf[n] = recommend;     // observe trend     int trend =sum (recommendBuf[i]) 0 <= i < n     if (trend == increase_(—)threshold) {      dyn_uncore_ratio = higher_uncore_ratio;     } else if(trend == decrease_(—) threshold) {      dyn_uncore_ratio =lower_uncore_ratio     } else { // no change      dyn_uncore_ratio =current_uncore_ratio;     }   }   if (dyn_uncore_ratio !=current_uncore_ratio) {    for (0 <= i < n) recommendBuf[i] = 0; //reset after recommending change   i = 0;   }   return dyn_uncore_ratio;}

In the code shown, uncore_floor is a quality of service (QoS) floorsetting, meaning the lowest uncore frequency allowed, while IO_Plimit isa floor adequate to sustain traffic comfortably from sibling sockets ina multi-socket assembly and/or attached IO devices. This parameter maybe a dynamic quantity based on traffic from these components.

Referring now to FIG. 3, shown is a block diagram of a processor inaccordance with another embodiment of the present invention. As shown inFIG. 3, a processor 300 may include a plurality of agents 310 ₀-310_(n). Each of these agents can correspond to a given traffic agent thatcan both act as a sink and a source of traffic communicated between theagents via an interconnect 315, which in the embodiment shown in FIG. 3is a ring interconnect. Although the scope of the present invention isnot limited in this regard, many different types of agents includingcores, processing engines, fixed function units, IO connections, memory,inter-socket connections among many others may be present.

To enable communication of traffic information for use in uncorefrequency control, further interconnections 330 a-330 n may be providedbetween each agent 310 and PCU 320. As seen, bidirectional paths may bepresent such that control information, e.g., to configure trafficsensors associated with each interconnect stop can be communicated. Inaddition, control signals to poll for or push information can beprovided. In turn, the corresponding traffic sensor data is communicatedto PCU 320.

Note that the illustration in FIG. 3 of the various agents 310 isgenerally understood to include a small portion of interconnect logic(generally referred to as an interface unit) including buffers, controllogic and so forth to enable communication of information between theagents via interconnect stops that interface between a given agent andinterconnect 315. In addition, these interconnect stops each may includeone or more traffic sensors. Although located at this position incertain embodiments, understand that the traffic sensors could beotherwise located such as at interfaces of the agents themselves, or atother portions along an interconnect.

Referring now to FIG. 4, shown is a block diagram of a traffic sensor inaccordance with an embodiment of the present invention. As shown in FIG.4, traffic sensor 370 may be a single traffic sensor located at aninterconnect stop or other interface logic associated with aninterconnect. In general, traffic sensor 370 may include variousstorages to provide for control and configuration of the sensor as wellas to enable maintaining traffic measurements in accordance with anembodiment of the present invention.

As seen in FIG. 4, traffic sensor 370 may include a control register380. In various embodiments, control register 380 may include aplurality of fields, each of which can be set under control of, e.g.,PCU logic. As seen, control register 380 can include a traffic typefield 372 for each type of communication possible on the interconnect,including a control field, an address field, a data field, and anacknowledgement field. In addition, control register 370 may include areset-on-read field 375, an index field 377, and a write field 378.

In general, the traffic type fields 372 (e.g., the control, address,data and acknowledgment fields) each can include a plurality of bitseach to indicate whether traffic of a particular direction is to becounted. Accordingly, these traffic type fields can act as a filter suchthat the traffic sensor only counts traffic in certain directions, e.g.,for efficiency and power consumption purposes. In one embodiment, threedimensions of directions can be controlled, namely north/south,east/west, in/out. In one embodiment, a logic high value for a given bitof any of these fields indicates that traffic of the corresponding typein the indicated direction is to be counted.

Note that the count operations themselves may occur by incrementing avalue in a corresponding one of multiple counters 390 ₀-390 _(m). Eachsuch counter may maintain a count of a data type along a given directiontuple.

Referring back to control register 370, reset-on-read field 375 may beset to indicate that counters 390 should be reset on a read operation.In turn, index field 377 may be used to index an individual count or themaximum of all counts. That is, in an embodiment a set of bit values maycorrespond to the counter to be read. For example, for 6 differentcounters (e.g., one kind of traffic type, up/down, in/out, left/right),3 bits may uniquely index one of the counters. Instead if index field377 is set to all zeros, a maximum of all counts may be provided.Finally, a write field 378 may be set responsive to a poll request sothat the indicated counter (e.g., according to index field 377) can bewritten into a status register 385. In various embodiments, statusregister 385 may thus contain the value to be read or be written and canbe sized to hold the maximum traffic count possible. Without loss ofgenerality, traffic can be determined as a function of traffic of eachtype and direction. Thus varied combinations of the traffic arepossible, such as weighting data more than acknowledgements.

Thus to effect a write of control register 370, the PCU may provide avalue to be stored in status register 385 and then on a write operation,e.g., as indicated by write field 379, the value in status register 385can be stored into control register 370. In so doing, a flexibleconfiguration of the traffic sensors is possible independent of eachother. Although shown at this high level in the embodiment of FIG. 4,understand that the scope of the present invention is not limited inthis regard. Furthermore, understand that traffic sensor 370 shown inFIG. 4 can be replicated at every interconnect stop. In manyembodiments, a single traffic sensor may be associated with eachinterconnect stop, e.g., at an input port or an output port, butimplementations may avoid providing two such traffic sensors perinterconnect stop for purposes of reducing real estate and powerconsumption. Further, understand that the PCU (e.g., PCU 320 of FIG. 3)may include a sensor mask to store information to selectively controloperation of the sensors. In one embodiment, this mask may include aplurality of bits each associated with a given traffic sensor. In thisway, sensors associated with interconnect stops can be turned off tosave power and processing time. For example, bits of a first (e.g.,high) state may enable the corresponding sensor and bits of a second(e.g., low) state may disable the corresponding sensor. In this way,interconnect stops that act as relays (or less critical stops) can bedisabled.

Thus in an embodiment, multiple traffic sensors can be provided, each tomeasure communication traffic at a point of an interconnect at which anagent is coupled. In such embodiment, the sensor can include a controlstorage to store control information to indicate a direction and a typeof communication traffic to be measured, a status storage to store atraffic measurement and to provide the measurement to a controllerresponsive to a request, and multiple counters each to store a trafficmeasurement for a direction and communication traffic type. Note thatthe controller can be incorporated into a PCU, and where the controllercan operate to set the control storage and read or be communicated thetraffic measurement from the status storage. The controller may alsoinclude a sensor mask to store a set of indicators, each associated witha sensor and having a first value to disable the corresponding sensorand a second value to enable the sensor.

According to various embodiments, UFS control may be configured using aUFS enable/disable flag in a CSR register, which may be readable once onsystem reboot. Note that this CSR may be the same CSR that stores theSPD flag, or it may be a different CSR. In addition, a user canconfigure an UFS adapt periodicity, which in an embodiment may be set interms of milliseconds, and may also be stored in a CSR such as a systemagent power management register. To perform UFS, power control circuitryuses data stored in an MSR that provides ceiling and floor values foruncore frequency.

In this way, a user can configure whether he wants: a full-featured UFSwith its associated power/performance benefits (and further providingthe ability to control UFS adapt periodicity); have the uncoreinterconnect operate at core frequency (provided single power domainoperation is enabled); or a fixed frequency uncore.

Customers having acceptable performance with their current deploymentbuying new server hardware could opt for uncore interconnect followingcore frequency so that these customers would instantly benefit fromfaster processor hardware. Customers/applications sensitive to memorylatency, data retrieval time or so forth, such as a search engineapplication could opt to disable UFS and set the floor and ceilinguncore frequency to obtain a fixed uncore frequency. Some users maychoose to experiment to determine an ideal floor value to meet a givenquality-of-service (QoS) metric. With an appropriately set floorfrequency, enabling the UFS feature would bring additionalpower/performance benefits.

For market segments with known application set characteristics, UFSadapt periodicity tuning is also possible by way of setting anobservation window length, which in an embodiment can be stored as afield of a control register as described above. In an embodiment, thisperiodicity tuning field may have a value that is set in integermultiples of a millisecond. The longer the observation window lengththat is selected, the less responsive is uncore frequency control tochanges in application set behavior. Very short windows on the otherhand may hinder forward progress of a given workload by way ofthrashing.

Referring now to Table 5 shown is pseudocode for implementingconfigurable UFS control in accordance with an embodiment of the presentinvention.

TABLE 5 If (follow_core) {   Update uncore frequency on every corePstate change } else {   if (uncore_floor != uncore_ceiling) {    if(time-to-run-UFS) { // can configure periodicity     // analyze uncoreinterconnect traffic, core stalls, IO traffic, intersocket traffic    // low → decrease uncore frequency     // high → increase uncorefrequency    }   } // else fixed uncore frequency }

In the code above of Table 5, if the UFS flag is disabled, the uncorefrequency may follow that of the core frequency (assuming a single powerdomain implementation) such that the uncore frequency is updated onevery update to core frequency. Otherwise, if the configured settingsfor uncore floor and ceiling values are not the same, and the adaptperiod is met, an analysis can be made of various information includinguncore interconnect traffic, core stalls, IO traffic, and inter-sockettraffic among other information. If such an analysis determines that theuncore frequency should be reduced, such frequency reduction may occur.Instead if it is determined based on the analysis that an increaseshould occur, such increase may occur. Note that in the situation wherethe floor and ceiling values are equal, a fixed uncore frequency may beprovided.

Power is non-linear with frequency when a processor is operating in theturbo range. Unless performance improvements are obtained by operatingin a turbo range, the increased power consumption is unjustified.Embodiments may use Energy Efficient Turbo (EET) to aid in thedetermination of core operating frequency in the turbo range based oncore metric information such as core stalls (degree of waiting of alllogical threads associated with a physical core for data loads orstores). Stalls are a function of workload mix and cache/memory accesspattern of the application running on the core. Cache-friendlyapplications are those whose entire working set fits in the cache. Incontrast, cache streaming or thrashing applications constantly seek newdata and sweep through the cache. Increased stalls indicate theapplication is unlikely to benefit from being run at a higher frequencywithout a commensurate reduction in stalls.

An EET algorithm that seeks to ramp a turbo-seeking core to a frequencyat which its stalls for memory are tolerable, as determined by aconfigurable threshold, that is operating efficiently, such that powerburned is proportional to performance obtained. The algorithm also takesinto consideration any user/OS specified energy performance bias (EPB).In one embodiment, the EPB may be based on user input to an OS-baseduser preference menu to indicate a user's preference as to apower/performance tradeoff. With a performance bias, an applicationrunning on a core that is not stalled may be granted a maximum turbofrequency, but with an energy bias the core may have its frequencyincremented by a unit step.

To effect an EET algorithm, embodiments may detect core stalls and coreactive cycles, e.g., via the core activity sensor and core stall sensor,to determine the proportion of cycles a core is stalled compared to thecycles it is active, termed core-centric unproductive time. Thiscore-centric unproductive time can be meaningful and reliable regardlessof the actual core and uncore interconnect operating frequencies, andthus serves well to classify a core as stalled or not using a singlethreshold. In various embodiments, this threshold may be configurableand can be a function of the system EPB.

The EET algorithm periodically analyzes all cores granted turbo mode todetermine whether their frequency should be increased, decreased or leftunchanged based on whether the core has been classified as stalled ornot over the observation interval. Cores running applications that fitin their private cache over consecutive observation cycles (providedthere exists power budget and no electrical, thermal or otherconstraints being violated) will reach the maximum turbo frequency. Inscenarios where the workload mix changes and there is increasing cachecontention, over time the turbo frequency of the affected cores will bereduced, e.g., steeply if the system is configured for energy bias ormore slowly if configured with performance bias.

Embodiments may implement the EET algorithm in firmware such as firmwareof a PCU of the processor. This algorithm may take as input hardwaresensor data regarding core stalls and core active cycles and anyuser/operating system configured energy performance bias to adapt thecore operating point.

Also understand that an EET algorithm may have wide flexibility as ituses configurable values for thresholds and the periodicity with whichit revisits turbo-granted cores. Further, the configuration can be afunction of the energy performance bias specified. The arithmeticexpression used to adapt the core frequencies can be a function of thecore stalls. A function is reasonable as long as it meets the followingcaveats: core frequency monotonically rises under favorable stallconditions and monotonically falls under unfavorable stall conditions.

As to the thresholds, assume a customer with a computer system includinga processor in accordance with an embodiment of the present inventionand a given OS runs their own application and has their own power,performance and quality of service needs. These values will be afunction of the EPB that the user/OS controls. In some embodiments,there may be a graphical user interface (e.g., dashboard) or other hooksto set these thresholds based on EPB. Note that each physical core mayhave an EPB corresponding to the minimum of its logical core EPBs.Referring now to Table 6 are example threshold values for differentEPBs. Note that these values can be tuned post-silicon using benchmarks.

TABLE 6 Deny Threshold Grant Threshold EPB Value Active Threshold(first) (second) Energy 20 50 10 Balanced 20 50 10 performance 20 60 20

In some embodiments, a processor may provide predetermined values forperformance, balanced and energy performance bias. In some embodiments,a second (grant) threshold may be less than a first (deny) threshold by2 to 8 times or more. In one embodiment, these are real numbers,representing a fraction of observation window time.

Without loss of generality, Table 7 below is pseudocode of animplementation of an EET algorithm in accordance with one embodiment ofthe present invention.

TABLE 7 Every Revisit Period { // period configurable, about 1millisecond   P1 = MAXIMUM_GUARANTEED_RATIO; // SKU based constant  MAXIMUM_TURBO; // SKU based constant   GRANT_K // a low configurableconstant 0 < GRANT_K < 1.0   DENY_K // a high configurable constant;DENY_K > 2 *   GRANT_K       // 0 < DENY_K < 1.0   for each core grantedturbo {    if (core_active_cycles >= min_activity_threshold) { ;    //configurable     //Demote or promote or no-change?     curr_pstate ; //retrieve current pstate of core     core_stall_cycles; // read sensordata from core      bias ;// retrieve energy-perf bias of core     if(core_stall_cycles >= core_active_cycles * DENY_K ) {     // demote      if (energy(bias)) { // energy bias         new_Pstate = P1 ; //exit Turbo       } else if (balance(bias)) {         new_Pstate = ((P1 +curr_pstate)/2 ; // less Turbo       } else { // performance bias, alittle less turbo         new_Pstate = maximum(curr_pstate − 1, P1)      }     } else if (core_stall_cycles >= core_active_cycles *    GRANT_K ) {       // promote .. further       if (energy(bias)) { ;// slow increase         new_Pstate = min (P1 + 1, MAXIMUM_TURBO)    }else if (balanced(bias)) { ; // faster increase          new_Pstate =(MAXIMUM_TURBO +          curr_pstate)/2     } else { // performancebias, shoot up to maximum turbo         new_Pstate = MAXIMUM_TURBO;      }     } // else in hysterisis region, no change     // apply allconstraints     new_pstate = min(new_pstate,           min(Electricaldesign point, Thermal, SKU, other    limits));     } // if_active   } //for-each loop

Note in Table 7 that after determination of a candidate performancestate (new_pstate), a minimum function is applied, which includeselectrical design point considerations, which is applied last because itdepends on the number of cores seeking to turbo and their degree ofturbo. Another parameter of the minimum function is a thermalconstraint, as past activity and environment affects processortemperature and thus how much the cores may turbo consequently withoutmelt down.

EET may be made available only in the context of PCPS, and can beenabled or disabled using configurable parameters in accordance with anembodiment. In one such implementation, an EET enable indicator such asan EET flag of a BIOS setting can be used to enable/disable EET. WhenEET is enabled, while a processor is operating in the turbo range,individual cores can operate at different, independent frequenciesdepending on the stalls encountered by the given core. In contrast, whenEET is disabled, a turbo budget is equally distributed among all coresseeking to operate at a turbo mode frequency.

As a further configurable parameter, an EET adapt period can be providedas a user controlled parameter by way of setting an adapt period length,which in an embodiment can be stored in a field of a control register.In an embodiment, this adapt period field may have a value that is setin integer multiples of a millisecond.

As examples of use cases for these EET configurable parameters, a cloudserver deployment may opt to turn off EET and in so doing distribute allturbo budget equally among all running applications (and can optionallydisable all turbo operation, allowing cores to run at most at maximumguaranteed frequency to keep cooling costs low). In a deployment whereit is possible to bill based on core frequency, turbo mode operation maybe turned on to enable billing on a sliding scale basis, chargingexponentially more for users operating in a turbo mode. As otherexamples, online e-commerce centers, such as banking, airlines, orentertainment streaming may choose to enable EET and gain increasedturbo performance where/when possible to meet dynamically peak load. Insystems where it is desired to cap cooling and power needs, turbo modemay be disabled, in which case EET is also disabled.

Referring now to Table 8, shown is pseudocode for performing EET controlin accordance with an embodiment of the present invention.

TABLE 8 If (turbo-enabled) {  if (!SINGLE_POWER_DOMAIN) {    if(EET_disabled) {    for all turbo cores distribute turbo power budgetequally      excess_power_budget/nurn-turbo-cores      operate turbocore at guaranteed_frequency + above per core      turbo budget   } else{    If (turbo period) { // can adjust periodicity    For all turbocores {     Based on energy efficiency policy and core stalls     Adaptcore operating frequency   }  } else {   Power distributed equally amongall active cores  } }

Thus in the code of Table 8 above, when a system is not in a singlepower domain mode and EET operation is disabled according to a disabledEET flag, a turbo power budget can be equally distributed to all coresseeking a turbo mode of operation by determining an excess power budgetand dividing this excess power budget by the number of cores seekingturbo operation. This allows each such core to operate at a commonfrequency above a guaranteed operating frequency. Otherwise, if EET isenabled and an adapt period has occurred; for each core seeking tooperate at a turbo mode of operation, the core operating frequency maybe adjusted based on a given energy efficiency policy and variousinformation such as core stall information. Such analysis and turbo modefrequency can be set, e.g., using the pseudocode shown above in Table 7,in one embodiment.

Referring now to FIG. 5, shown is a block diagram of a processor inaccordance with an embodiment of the present invention. As shown in FIG.5, processor 400 may be a multicore processor including a plurality ofcores 410 _(a)-410 _(n). In one embodiment, each such core may beconfigured to operate at multiple voltages and/or frequencies. Inaddition, each core may be independently controlled to operate at aselected voltage and/or frequency, as discussed above. To this end, eachcore may be associated with a corresponding voltage regulator 412 a-412n. While not shown for ease of illustration, understand that each core410 can include a core activity sensor and a core stall sensor. Thevarious cores may be coupled via an interconnect 415 to an uncore orsystem agent logic 420 that includes various components. As seen, theuncore 420 may include a shared cache 430 which may be a last levelcache. In addition, the uncore may include an integrated memorycontroller 440, various interfaces 450 and a power control unit 455, aswell as the distributed traffic sensors described above.

In various embodiments, power control unit 455 may be in communicationwith OS power management code, affected by the OS writing to a MSR, oneper logical processor. For example, based on a request received from theOS and information regarding the workloads being processed by the cores,power control unit 455 may use included power management configurationcontrol logic 457 that in one embodiment may execute firmware to enablea user to control implementation of multiple power management featuresin accordance with one embodiment of the present invention. Based on theabove-described information, power control unit 455 can dynamically andindependently control a frequency and/or voltage to one or more cores inlight of the core's activity levels.

With further reference to FIG. 5, processor 400 may communicate with asystem memory 460, e.g., via a memory bus. In addition, by interfaces450, connection can be made to various off-chip components such asperipheral devices, mass storage and so forth. While shown with thisparticular implementation in the embodiment of FIG. 5, the scope of thepresent invention is not limited in this regard.

Referring now to FIG. 6, shown is a block diagram of a processor core inaccordance with one embodiment of the present invention. As shown inFIG. 6, processor core 500 may be a multi-stage pipelined out-of-orderprocessor. As shown in FIG. 6, core 500 may operate at various voltagesand frequencies as a result of integrated voltage regulator 509. Invarious embodiments, this regulator may receive an incoming voltagesignal, e.g., from an external voltage regulator and may further receiveone or more control signals, e.g., from uncore logic coupled to core500.

As seen in FIG. 6, core 500 includes front end units 510, which may beused to fetch instructions to be executed and prepare them for use laterin the processor. For example, front end units 510 may include a fetchunit 501, an instruction cache 503, and an instruction decoder 505. Insome implementations, front end units 510 may further include a tracecache, along with microcode storage as well as micro-operation storage.Fetch unit 501 may fetch macro-instructions, e.g., from memory orinstruction cache 503, and feed them to instruction decoder 505 todecode them into primitives, i.e., micro-operations for execution by theprocessor.

Coupled between front end units 510 and execution units 520 is anout-of-order (OOO) engine 515 that may be used to receive themicro-instructions and prepare them for execution. More specifically OOOengine 515 may include various buffers to re-order micro-instructionflow and allocate various resources needed for execution, as well as toprovide renaming of logical registers onto storage locations withinvarious register files such as register file 530 and extended registerfile 535. Register file 530 may include separate register files forinteger and floating point operations. Extended register file 535 mayprovide storage for vector-sized units, e.g., 256 or 512 bits perregister.

Various resources may be present in execution units 520, including, forexample, various integer, floating point, and single instructionmultiple data (SIMD) logic units, among other specialized hardware. Forexample, such execution units may include one or more arithmetic logicunits (ALUs) 522, among other such execution units.

Results from the execution units may be provided to retirement logic,namely a reorder buffer (ROB) 540. More specifically, ROB 540 mayinclude various arrays and logic to receive information associated withinstructions that are executed. This information is then examined by ROB540 to determine whether the instructions can be validly retired andresult data committed to the architectural state of the processor, orwhether one or more exceptions occurred that prevent a proper retirementof the instructions. Of course, ROB 540 may handle other operationsassociated with retirement.

As shown in FIG. 6, ROB 540 is coupled to a cache 550 which in oneembodiment may be a low level cache (e.g., an L1 cache), although thescope of the present invention is not limited in this regard. Also,execution units 520 can be directly coupled to cache 550. From cache550, data communication may occur with higher level caches, systemmemory and so forth. While shown with this high level in the embodimentof FIG. 6, understand the scope of the present invention is not limitedin this regard. For example, while the implementation of FIG. 6 is withregard to an out-of-order machine such as of a so-called x86 instructionset architecture (ISA), the scope of the present invention is notlimited in this regard. That is, other embodiments may be implemented inan in-order processor, a reduced instruction set computing (RISC)processor such as an ARM-based processor, or a processor of another typeof Instruction Set Architecture (ISA) that can emulate instructions andoperations of a different ISA via an emulation engine and associatedlogic circuitry.

Referring now to FIG. 7, shown is a block diagram of a multicoreprocessor in accordance with another embodiment of the presentinvention. As shown in the embodiment of FIG. 7, processor 600 includesmultiple domains. Specifically, a core domain 610 can include aplurality of cores 610 ₀-610 n, a graphics domain 620 can include one ormore graphics engines, and a system agent domain 650 may further bepresent. In various embodiments, system agent domain 650 may handlepower control events and power management such that individual units ofdomains 610 and 620 such as cores and/or graphics engines can becontrolled to independently dynamically operate at an appropriate turbomode frequency in light of the activity (or inactivity) occurring in thegiven unit. Each of domains 610 and 620 may operate at different voltageand/or power, and furthermore the individual units within the domainseach may operate at an independent frequency and voltage based on userconfiguration of power management features as described herein. Notethat while only shown with three domains, understand the scope of thepresent invention is not limited in this regard and additional domainscan be present in other embodiments.

In general, each core 610 may further include low level caches inaddition to various execution units and additional processing elements.In turn, the various cores may be coupled to each other and to a sharedcache memory formed of a plurality of units of a LLC 640 ₀-640 _(n). Invarious embodiments, LLC 640 may be shared amongst the cores and thegraphics engine, as well as various media processing circuitry. As seen,a ring interconnect 630 thus couples the cores together, and providesinterconnection between the cores, graphics domain 620 and system agentcircuitry 650. In one embodiment, interconnect 630 can be part of thecore domain. However in other embodiments the ring interconnect can beof its own domain, and can be controlled to operate at an independent ordependent frequency based on the configurable UFS control describedherein.

As further seen, system agent domain 650 may include display controller652 which may provide control of and an interface to an associateddisplay. As further seen, system agent domain 650 may include a powercontrol unit 655 which can include a turbo control logic 659 inaccordance with an embodiment of the present invention to control aturbo mode frequency of the cores either independently or at a commonturbo mode frequency based on activity information of the correspondingcore and the EET configuration.

As further seen in FIG. 7, processor 600 can further include anintegrated memory controller (IMC) 670 that can provide for an interfaceto a system memory, such as a dynamic random access memory (DRAM).Multiple interfaces 680 ₀-680 _(n) may be present to enableinterconnection between the processor and other circuitry. For example,in one embodiment at least one direct media interface (DMI) interfacemay be provided as well as one or more Peripheral Component InterconnectExpress (PCIe™) interfaces. Still further, to provide for communicationsbetween other agents such as additional processors or other circuitry,one or more interfaces in accordance with an Intel® Quick PathInterconnect (QPI) protocol may also be provided. Although shown at thishigh level in the embodiment of FIG. 7, understand the scope of thepresent invention is not limited in this regard.

Embodiments may be implemented in many different system types. Referringnow to FIG. 8, shown is a block diagram of a system in accordance withan embodiment of the present invention. As shown in FIG. 8,multiprocessor system 700 is a point-to-point interconnect system, andincludes a first processor 770 and a second processor 780 coupled via apoint-to-point interconnect 750. As shown in FIG. 8, each of processors770 and 780 may be multicore processors, including first and secondprocessor cores (i.e., processor cores 774 a and 774 b and processorcores 784 a and 784 b), although potentially many more cores may bepresent in the processors. Each of the processors can include a PCU orother logic to perform dynamic control of a permitted operatingfrequency greater than a guaranteed operating frequency (independentlyor at a common turbo mode frequency) based on core activity occurring toefficiently consume energy, as described herein, as well as enablingsingle domain power control or PCPS power control. Based on theconfigurable settings described herein, the processors may furthercontrol uncore frequency according to a given configuration.

Still referring to FIG. 8, first processor 770 further includes a memorycontroller hub (MCH) 772 and point-to-point (P-P) interfaces 776 and778. Similarly, second processor 780 includes a MCH 782 and P-Pinterfaces 786 and 788. As shown in FIG. 8, MCH's 772 and 782 couple theprocessors to respective memories, namely a memory 732 and a memory 734,which may be portions of system memory (e.g., DRAM) locally attached tothe respective processors. First processor 770 and second processor 780may be coupled to a chipset 790 via P-P interconnects 752 and 754,respectively. As shown in FIG. 8, chipset 790 includes P-P interfaces794 and 798.

Furthermore, chipset 790 includes an interface 792 to couple chipset 790with a high performance graphics engine 738, by a P-P interconnect 739.In turn, chipset 790 may be coupled to a first bus 716 via an interface796. As shown in FIG. 8, various input/output (I/O) devices 714 may becoupled to first bus 716, along with a bus bridge 718 which couplesfirst bus 716 to a second bus 720. Various devices may be coupled tosecond bus 720 including, for example, a keyboard/mouse 722,communication devices 726 and a data storage unit 728 such as a diskdrive or other mass storage device which may include code 730, in oneembodiment. Further, an audio I/O 724 may be coupled to second bus 720.Embodiments can be incorporated into other types of systems includingmobile devices such as a smart cellular telephone, tablet computer,netbook, Ultrabook™, or so forth.

By providing configuration of processor performance features, andfacilitating their mixing and matching, a single processor can bettermeet the needs of different market segments without an explosion ofSKUs. By providing a SPD indicator as described above, in conjunctionwith firmware (hardware and software support) a processor can functionboth as a prior generation product and a new full featured productseamlessly and further can enable a legacy OS-based system to exploitPCPS in a manner that is invisible to the OS.

By providing configurable control of UFS, an interconnect system canoperate where uncore frequency follows core frequency, or as a fixeduncore frequency product, or as a dynamic workload sensitive adaptiveinterconnect system. In addition, the periodicity parameter allowscontrol of system response speed to workload changes.

The EET enable/disable feature allows equal distribution of availableturbo budget among turbo requesting cores or more careful control, e.g.,based on application memory dependency characteristics.

Using embodiments of the present invention, latency sensitive customerscan set an uncore frequency floor high enough to meet QoS needs, or setthe floor and ceiling to the same value to turn off UFS. Customers whoseek to benefit from new hardware but not new power features can turnoff all of the above-described power management features. Alternatelyusers such as cloud server usage models could disable these featuresuntil such point as support to bill their customers/applications basedon usage is available. For other users such as in-house data centers,all of the above-described power management features can be exploited togain power/performance benefits. Finally, legacy OS customers can usethese features although they are invisible and not supported by the OS.

Embodiments may be used in many different types of systems. For example,in one embodiment a communication device can be arranged to perform thevarious methods and techniques described herein. Of course, the scope ofthe present invention is not limited to a communication device, andinstead other embodiments can be directed to other types of apparatusfor processing instructions, or one or more machine readable mediaincluding instructions that in response to being executed on a computingdevice, cause the device to carry out one or more of the methods andtechniques described herein.

Embodiments may be implemented in code and may be stored on anon-transitory storage medium having stored thereon instructions whichcan be used to program a system to perform the instructions. The storagemedium may include, but is not limited to, any type of disk includingfloppy disks, optical disks, solid state drives (SSDs), compact diskread-only memories (CD-ROMs), compact disk rewritables (CD-RWs), andmagneto-optical disks, semiconductor devices such as read-only memories(ROMs), random access memories (RAMs) such as dynamic random accessmemories (DRAMs), static random access memories (SRAMs), erasableprogrammable read-only memories (EPROMs), flash memories, electricallyerasable programmable read-only memories (EEPROMs), magnetic or opticalcards, or any other type of media suitable for storing electronicinstructions.

While the present invention has been described with respect to a limitednumber of embodiments, those skilled in the art will appreciate numerousmodifications and variations therefrom. It is intended that the appendedclaims cover all such modifications and variations as fall within thetrue spirit and scope of this present invention.

What is claimed is:
 1. A processor comprising: a plurality of cores toindependently execute instructions; a control register to store a singlepower domain indicator to indicate whether the plurality of cores are tobe treated as a single power domain to operate at a common performancestate; a voltage regulator to independently provide a regulated voltageto each of the plurality of cores to enable each of the plurality ofcores to be an independent power domain and to operate at an independentperformance state; and a power controller to cause the voltage regulatorto provide a different regulated voltage to at least one of theplurality of cores to cause the at least one core to operate at theindependent performance state based on a state of the single powerdomain indicator.
 2. The processor of claim 1, wherein the powercontroller is to cause the at least one core to execute at a performancestate most recently requested by a thread that is to execute on the atleast one core.
 3. The processor of claim 1, wherein the powercontroller is to cause the at least one core to execute at a performancestate corresponding to a maximum performance state of a plurality ofperformance states each requested by one of a plurality of threads thatare to execute on the at least one core.
 4. The processor of claim 1,wherein the power controller is to enable the independent performancestate operation in a system having a legacy operating system (OS) thatdoes not provide for independent performance state operation.
 5. Theprocessor of claim 1, wherein the power controller is to access a tableassociated with a basic input/output system (BIOS), the table having aplurality of entries each to indicate a power management mode for acorresponding core of the plurality of cores.
 6. The processor of claim5, wherein in a first power management mode, the power controller is tocause the at least one core to execute at a performance state mostrecently requested by a thread that is to execute on the at least onecore, and in a second power management mode to cause the at least onecore to execute at a performance state corresponding to a maximumperformance state of a plurality of performance states each requested byone of a plurality of threads that are to execute on the at least onecore.
 7. The processor of claim 1, wherein the processor is to updatethe single power domain indicator of the control register in a securemode of operation.
 8. The processor of claim 1, wherein the powercontroller is to cause the plurality of cores to execute at a highestperformance state requested by a plurality of threads executing on anyof the plurality of cores when the single power domain indicatorindicates that the plurality of cores are to be a single power domain.9. The processor of claim 1, further comprising a second controlregister to store a frequency scaling indicator to indicate whether toenable a frequency scaling logic of the power controller, the frequencyscaling logic to dynamically control a frequency of a system agentcircuitry of the processor.
 10. The processor of claim 9, wherein thesecond control register is to further store a periodicity value, theperiodicity value corresponding to an interval at which the frequencyscaling logic is to execute, when enabled.
 11. The processor of claim10, further comprising a machine specific register to store a floorvalue for the system agent circuitry frequency and a ceiling value forthe system agent circuitry frequency.
 12. The processor of claim 11,wherein the frequency scaling logic is to operate the system agentcircuitry at a fixed frequency when the floor value equals the ceilingvalue.
 13. The processor of claim 1, further comprising a third controlregister to store a flag to indicate whether a power budget is to beequally distributed to a subset of the plurality of cores that are toexecute in a turbo mode.
 14. The processor of claim 13, wherein when theflag is of a first state, the power controller is to enable each core ofthe subset to operate at an independent turbo mode frequency and whenthe flag is of a second state, the power controller is to enable all ofthe subset to operate at a common turbo mode frequency.
 15. Theprocessor of claim 14, wherein when the flag is of the first state, thepower controller is to determine the independent turbo mode frequencyfor each core of the subset based at least in part on stall informationof the corresponding core of the subset.
 16. An apparatus comprising: aplurality of cores to independently execute instructions; a plurality ofvoltage regulators each to independently provide a voltage to at leastone of the plurality of cores; system agent circuitry including at leastone cache memory, a memory controller, and an interconnect to couple theplurality of cores and the at least one cache memory, the interconnectincluding a plurality of interface units each to couple the interconnectto one of the plurality of cores, wherein each of the interface unitsincludes a traffic sensor to measure traffic at a location of theinterconnect associated with the interface unit; a control register tostore a frequency scaling indicator to indicate whether dynamic controlof a frequency of the interconnect is enabled; and a frequency scalinglogic to receive information regarding the traffic from at least some ofthe plurality of traffic sensors to control the interconnect frequencybased on at least some of the information, when enabled by the frequencyscaling indicator.
 17. The apparatus of claim 16, wherein each of theplurality of cores further includes an activity sensor to generate anactivity value and a stall sensor to generate a stall value, and thecorresponding core is to communicate the activity value and the stallvalue to the frequency scaling logic for an observation interval. 18.The apparatus of claim 17, wherein the frequency scaling logic is tocause the interconnect frequency to be increased based on the stallvalue for at least some of the plurality of cores.
 19. The apparatus ofclaim 18, wherein the frequency scaling logic is to cause theinterconnect frequency to be increased based on a threshold number ofcores having a stall value exceeding a stall threshold.
 20. A systemcomprising: a processor including a plurality of cores, a plurality ofvoltage regulators each to independently provide a voltage to at leastone of the plurality of cores, a first configuration register to store apower domain indicator to indicate whether the plurality of cores are tobe controlled as a common power domain, a second configuration registerto store an enable indicator to indicate whether the plurality of coresare to be operated at a common turbo mode frequency in a turbo mode, anda power control unit (PCU) to control the plurality of voltageregulators to provide independent voltages to at least some of theplurality of cores when the plurality of cores are to be controlled asindependent power domains, the PCU comprising a turbo mode control logicto concurrently enable a first core of the plurality of cores to operateat a first turbo mode frequency and a second core of the plurality ofcores to operate at a second turbo mode frequency when the enableindicator is of a first state; and a dynamic random access memory (DRAM)coupled to the processor.
 21. The system of claim 20, wherein the turbomode control logic is to concurrently enable the first and second coresof the plurality of cores to operate at the common turbo mode frequencywhen the enable indicator is of a second state.
 22. The system of claim21, wherein the turbo mode control logic is to determine a turbo modepower budget and calculate the common turbo mode frequency based on theturbo mode power budget and a number of the plurality of cores that seekoperation in the turbo mode.
 23. The system of claim 20, wherein the PCUfurther includes a frequency scaling logic to receive informationregarding traffic on an interconnect that couples the plurality of coresand to control a frequency of the interconnect based on at least some ofthe information.